Goal: Merge the changes we made in branch1 into master branch. We will use the ex02 repo we created previously.
NOTE: This is done on the website!
You will get the following dialog.
branch1 into master, ensure that your page looks as below showing the source and target branches.Merge button, you will get the following dialog with the checkbox indicating that the merge has been made.ex02 on top left, you will see that the master branch has all the changes that belonged to branch1, i.e. both are identical.Let us go back to ex02 and work further on branch1.
master branch. Notice that you don’t see the merged changes. Use Pull in the Git tab to sync up: you will see the files change.Switch to branch1 in Rstudio and make further edits to README.md by adding Edited a bit more after merge request.
Commit with message Commit after Merge Request and push changes.
Check that GitLab reflects the changes to branch1.
Switch back to master branch on Rstudio and create another branch branch2 off the master branch.
Now edit the file README.md again and add a line Update from branch2.
Commit with message Commit from branch2 and push branch2.
master, branch1, branch2.branch2 into master on the website and complete the merge with message Merge Request from Branch2.Submit the merge request.
Go ahead and merge it but once again, do not delete source branch.
In Rstudio, use Pull to pull in the changes. Notice how branch2 changes are now in master.
Go back to GitLab and make a Merge Request from branch1 into master on the website and try to complete the merge with message Merge from Branch1 after Branch2.
Go ahead and merge it but do not delete source branch.
What happened? Here is the picture that helps.
<<<<<<<<<<<
and
>>>>>>>>>>>
delimeters. We reconcile it and note it and mark as resolved.
You can now fetch and pull from the origin in Rstudio to have sanity back.
You can also delete the branches, now that they have served their purpose.
The conflict resolution issue is what I get asked most about especially by team members on a project.
Most of the time, collaborators are working on different parts of project code or documentation and so this is usually not a problem.
To prevent it from becoming a major problem, it is best to make incremental changes in branches as I advise below. That way, it is easy to narrow down what the source of the conflict.
Commiting and pushing often to origin ensures that your changes are never lost. It also lets your collaborator know what you are doing and surface any potential conflicts.
Make a merge request as soon as you think you have finished a feature and try to merge it, so that don’t go too far down the development process which can cause conflict resolution to become very complicated.
I create a branch whenever I want to make some feature changes. Making changes in my branch is a good way to create my edits away from the master branch.
If you don’t use branches, you are working directly with the master branch.
To create a new branch, I execute
which creates a local branch named mybranch.
Now I have to inform the remote repo that I have a new branch as shown below.
Now I can do all my work with my branch as follows, first by checking it out.
I then make my changes as usual and do commits and push changes upstream as outlined earlier. When I push my branch to the remote repo, I can choose to merge my branch into the master. I have to approve it and in the process resolve any conflicts that may arise. Once it is approved, stuff from my branch, gets merged into the master branch.
Once done with a branch, I can delete it.
This does not affect the changes that have already been merged into the master via my merge request.
When you delete branches on remote repository, Rstudio, not being a full Git IDE, can sometimes get confused.
In such cases, I quite Rstudio, and if I am sure that the remote repository is fully updated and current, I would either rename my project directory and clone the repo again to synchronize.
Yes, unfortunately, Rstudio only goes so far.